What the bug is: Every other entry in perf-changelog.yaml fills pr-link with either a concrete https://github.com/SemiAnalysisAI/InferenceX/pull/<n> URL or the sanctioned XXX placeholder that merge tooling auto-fills. This PR's new entry (appended at line 4792) instead uses the literal string TBD, which is not a value the changelog tooling recognizes.

Where it breaks: utils/validate_perf_changelog.py defines PR_LINK_PLACEHOLDERS = {"XXX", "https://github.com/SemiAnalysisAI/InferenceX/pull/XXX"}. Its validate_added_pr_link(link, pr_number) function checks: if a PR number is known, the link must equal the expected canonical URL or be one of PR_LINK_PLACEHOLDERS — otherwise it raises ChangelogValidationError("new PR entry must use '<url>' or an XXX placeholder; found '<link>'"). TBD satisfies neither condition.

Why PR-time checks don't catch it: The sweep-gate path (run-sweep.yml → validate_perf_changelog.py main → process_changelog.py) does not call validate_added_pr_link at all — and separately, ChangelogEntry.pr_link in matrix_logic/validation.py is an unconstrained str, so any string passes Pydantic validation. This is exactly why the issue is invisible in the PR's green checks.

Where it does fire: utils/merge_with_reuse.sh, the repository's standard reuse-assisted merge path (used by the merge-prs skill), unconditionally runs prepare_perf_changelog_merge.py canonicalize --pr-number <PR> after merging main (line 181), regardless of whether a conflict occurred. canonicalize_appended_links() calls compare_entries(base, head, pr_number), which for every appended entry calls validate_added_pr_link(entry['pr-link'], pr_number). With pr_number=2218 and link='TBD', this raises ChangelogValidationError: new PR entry must use 'https://github.com/SemiAnalysisAI/InferenceX/pull/2218' or an XXX placeholder; found 'TBD'.

Step-by-step proof:

1. PR [NV] Add gb300 nvfp4 qwen3.5 MTP 8k1k recipes  #2218 is merged/rebased via merge_with_reuse.sh.
2. After the main-merge step, the script calls prepare_perf_changelog_merge.py canonicalize --changelog-file perf-changelog.yaml --base-ref origin/main --pr-number 2218 --repo SemiAnalysisAI/InferenceX.
3. canonicalize_appended_links parses base vs. head, finds one appended entry (qwen3.5-fp4-gb300-dynamo-trt-mtp), and calls validate_added_pr_link('TBD', 2218).
4. expected = 'https://github.com/SemiAnalysisAI/InferenceX/pull/2218'; 'TBD' not in PR_LINK_PLACEHOLDERS and 'TBD' != expected → ChangelogValidationError is raised.
5. merge_with_reuse.sh exits non-zero at that step, blocking the automated merge until someone manually fixes the changelog entry.

Impact and fix: Had the author used the sanctioned XXX placeholder, canonicalize_appended_links would have auto-rewritten it to the real /pull/2218 link and the merge would proceed silently. Using TBD instead turns what should be a no-op auto-fix into a hard failure of the standard merge tooling. The fix is a one-line change: replace TBD with either XXX or the literal https://github.com/SemiAnalysisAI/InferenceX/pull/2218.

The new perf-changelog.yaml entry for qwen3.5-fp4-gb300-dynamo-trt-mtp is internally self-contradictory. The first description bullet correctly states "Add Qwen3.5-397B-A17B-NVFP4 GB300 disaggregated TensorRT-LLM+Dynamo MTP (3-token) benchmarks for 8k1k," but the third bullet begins "9 STP configs: 1P1D DEP2+1D TEP16 (conc 48), ...". STP (single-token prediction, i.e. no speculative decoding) and MTP (multi-token prediction, 3 speculative draft tokens) are different decoding modes, and this entry unambiguously documents the latter.

Every piece of evidence in this PR confirms these are MTP recipes: the master-config key is qwen3.5-fp4-gb300-dynamo-trt-mtp with every search-space point set to spec-decoding: "mtp"; all 9 new recipe filenames under benchmarks/multi_node/srt-slurm-recipes/trtllm/qwen3.5/gb300-fp4/disagg/8k1k/mtp/ contain mtp3; and every recipe's speculative_config block sets decoding_type: MTP with max_draft_len: 3. There is no STP recipe anywhere in this diff.

The likely root cause is that this changelog entry was drafted by copying the changelog entry from the sibling STP recipes PR (#2206), which does add STP configs, and the "STP" wording in the count line was never updated to match the MTP content being described here — while the first bullet was correctly edited to say "MTP."

Step-by-step proof:

1. Read perf-changelog.yaml lines 4784-4792 (new entry): bullet 1 says "...MTP (3-token) benchmarks..."; bullet 3 says "9 STP configs: ...".
2. Read configs/nvidia-master.yaml, new key qwen3.5-fp4-gb300-dynamo-trt-mtp: every one of the 9 search-space entries sets spec-decoding: "mtp".
3. Read any of the 9 new recipe YAMLs, e.g. ctx1dep2_gen1tep16_mtp3_c48.yaml: both prefill.speculative_config.decoding_type and decode.speculative_config.decoding_type are MTP with max_draft_len: 3.
4. Filenames themselves encode mtp3 (3-token MTP), not stp.
5. Therefore "STP" in bullet 3 is factually wrong for the content it describes and contradicts bullet 1 of the same entry.

This is purely a documentation string in a changelog file with no functional/runtime impact — it doesn't affect recipe execution, CI, or the master config — so it does not block merge. The fix is a one-word edit: change "9 STP configs" to "9 MTP configs" on line 4790.